1. Field of Invention
The present invention relates to a method and a system for converting the service type of an open platform, and particularly to a method and a system for converting the service types of the devices connected to a control gateway.
2. Description of the Related Art
Along with the digital home trend and Internet emerging growth, a variety of residential network protocols (RNPs) and agency platforms comes out too. The so-called “heterogeneous network integration” becomes a new focus and big challenge for the development of the digital home. Several years ago, Open Services Gateway Initiative Alliance (OSGi Alliance) provided an open service platform, which is one of the solutions just reflecting such demand.
In the current OSGi specification, only two connection modes are defined. One of the connection modes is the Device Access specification defined in chapter 11 thereof, which defines how a driver corresponding to a physical device connected to an open service residential gateway (open service RG) is downloaded. The other connection mode is the connection through network defined in chapter 25 of the OSGi specification, which includes such as: converting an OSGi service into a standard Universal Plug and Play (UPnP) device service; providing the converted OSGi service to internal multi-service bundles or external UPnP control points for use.
As a matter of fact, not all devices of a digital home are connected to the residential gateway (RG); moreover, not all devices are powerful to handle Internet access communication. As an alternative solution to meet such situation, however, a usually available device connection mode is to connect some plain devices with simple functions to a function-powerful control gateway, while the open platform of an RG would indirectly control the plain devices in a sub-hierarchy and linked thereto through the control gateway. A home security layout is an example, wherein simple sensors are connected to a function-powerful master controller to achieve the integration control goal; a so-called LonWorks network framework commonly available on the market is another example, wherein LonWorks standard devices are connected to a LonWorks server for indirectly controlling the LonWorks standard devices through the LonWorks server. In the framework, an open platform is unable to directly communicate with the devices connected to the control gateway, but it can control the connected devices through the control gateway. So-called LonWorks herein is an acronym of Local Operating Networks and is a networking platform, created by German company of Echelon.
In terms of the above-mentioned framework in connection to a plurality of devices under a control gateway, if the framework is implemented according to the OSGi Device Access specification, the control gateway and all the devices thereunder are considered as a large set of virtual devices. Then, the drivers of the set of virtual devices are downloaded, wherein the downloaded drivers should include the control gateway driver and a set of the individual drivers corresponding to all the devices connected to the control gateway. According to such a scheme, to newly add or remove a device connected to the control gateway, the previously downloaded drivers are not applicable any more. Instead, it needs to download a driver set corresponding to the new set of virtual devices again.
In other words, according to the above-described scheme, the control gateway and all the devices thereunder are considered as a unique and stiff device unable to be changed. Obviously, it is not a feasible solution that all original drivers must be deleted and a new packet of drivers must be downloaded again for the sake of adding or removing a device. In addition, the job to download a packet of drivers is extremely time-consuming and prone to be disconnected. Consequently, the above-described scheme is apparently very ineffective.
In terms of the UPnP device service standard established by the OSGi specification 3rd ver., only an interface is provided in the standard for those non-UPnP devices to be converted into the UPnP standard device service so as to serve the internal multi-service bundles or the external UPnP control points for use or control; besides, the standard also provides a mechanism of UPnP base drivers, by which the UPnP device service of an UPnP device can be automatically registered on the service registry of an open service RG (residential gateway). For the above-described framework where a plurality of devices is connected to a control gateway underneath, however, since an open platform is unable to directly communicate with the devices connected to the control gateway, there is no way to provide those devices with a mechanism of converting the devices into various device services and downloading the corresponding device services. Thus, the UPnP device service standard established by the 3rd version of OSGi specification is unable to solve the problem associated with the framework where a plurality of devices is connected to a control gateway.
Currently, in the related available technical papers, the discussed issues are mostly focused on how to integrate an communication protocol or an agency software with non-OSGi standard into an open service platform. For example, the paper “Service-based Access to Distributed Embedded Devices through the Open Service Gateway” describes that how devices of HAVi (home audio video interoperability) on CAN (control area network) are re-registered on the service registry of an open service RG (residential gateway) after packaging the devices into a control service through two mechanisms of the OSGi Device Access standard and JNI (java native interface) for achieving the integration and control goal. Unfortunately, so far there has been no paper to discuss how to integrate a device controlled through a control gateway into an open service platform yet.
The other related papers are involved in discussing the issue that how to convert one communication protocol or standard into another one. For example, the paper “Device and Service Discovery in Home Network with OSGi” discusses a mutual converting mechanism between Jini standard and OSGi standard or between UPnP and OSGi standard. However, the proposed method is limited to converting of Jini and UPnP device services; besides, the physical device itself must be capable of device discovery and control. Hence, the above-mentioned papers do not give a solution in practice for the devices which are unable to be directly controlled and require a control gateway to control them.
Except for the above-mentioned papers, most of the related patents focus on how to take advantage of a corresponding mechanism generated on an open service platform to obtain the function of controlling the devices originally controlled by other standard agency protocols. US Patent Application No. 20040267950 is an example of the sort of patents. In addition, some other patents focus on how to take advantage of other more popular or universal means and schemes to achieve the goal of controlling devices, for example, the US Patent Application No. 20010034754. Nevertheless, the above-mentioned patents still do not touch the issue how to integrate devices connected to a control gateway into an open service platform.